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[57] ABSTRACT 

A method and apparatus for providing inter-program 
co mm unication, and in particular, the sharing of algo- 
rithms among programs. A “services server” scans pro- 
grams stored in the mass storage of a computer system 
and generates a data structure containing attribute in- 
formation of each service provided by the programs 
stored in mass storage. This data structure includes an 
attribute name, the “sendType” of the attribute and the 
“retumTypes” of the attribute. A sendType is the re- 
quired format of data provided to the service provider 
as an input to the service algorithm. The retumType is 
the format of data that is the result of applying the 
service algorithm to the input data. SendTypes and 
retumTypes are ASCII, RTF, TIFF, PICT, etc. When 
a service requestor is activated, the service requestor 
scans the services server data structure and generates its 
own local database of available services with which it 
can provide the appropriate data format. For example, 
if a service requestor cannot communicate in graphical 
formats, such as PICT or TIFF, those service providers 
on the server database are not retrieved. The service 
requestor then generates a display list, such as a menu, 
of available services for a user. When a user wishes to 
access a service, the user makes a selection which is 
data, such as text, graphics, etc. Depending on the for- 
mats in which the selection can be represented, only 
certain of the initially available services may currently 
be valid. 

35 Claims, 4 Drawing Sheets 
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METHOD AND APPARATUS FOR 
INTER-PROGRAM COMMUNICATION 

This is a continuation of application Ser. No. 5 
07/629,222 filed Dec. 17, 1990 now abandoned. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

This invention relates to the field of communication 10 
between programs and more particularly, to a method 
of providing a system for sharing algorithms among 
programs. 

2. Background Art 

A computer system may include a number of pro- 15 
grams available for use by a computer user. Communi- 
cation between programs may be desired in certain 
instances. For example, it is often desired to share data 
between a spreadsheet program and a database manage- 
ment program. Thus, the spreadsheet program and 20 
database management program must be able to commu- 
nicate with each other in a mutually understandable 
manner. In other instances, a program may require a 
function or functionality of another program. 

In the prior art, inter-program communication is 25 
characterized by “data-sharing” schemes and tech- 
niques known as “cold links,” “hot links” and “warm 
links.” These data sharing schemes are directed to hav- 
ing data appear in two or more places in the same or 
different forms. 30 

For example, it is possible on some computer systems 
to copy a picture from a drafting program and “paste” 
it into a word processing program. Once pasted into a 
word processing program document, no editing of the 
picture may be accomplished, since the word process- 35 
ing program does not include tools for editing graphics. 

In a cold link system, a link is created between the 
pasted picture and the drawing program. If a user is 
using the word processing program and accesses the 
document containing graphics, and if the user desires to 40 
edit the graphic, the user performs some operation 
(such as “double clicking”) on the graphics document. 
This activates the link and sends a message to the draw- 
ing program to launch itself so that the drawing pro- 
gram becomes active and the graphics can be edited. 45 

In a hot link system, information can be shared 
among a number of programs. Whenever that informa- 
tion is altered in one program, all other instances of that 
information are altered in the other programs as well. 
For example, a user may copy data from a database 50 
management program and paste it into a spreadsheet 
program document for display. If the copied data is 
later altered in the database management program, the 
hot link causes the data of the spreadsheet program to 
be automatically altered in the same manner as the origi- 55 
nal information. 

In warm links, information that is shared by more 
than one program is stored in a central location. Pro- 
grams that share that information are “subscribers” to 
the information. Periodically, the subscribers poll the 60 
storage location, and thus have access to the updated 
version of the shared file. Alternatively, the “publisher” 
(program that alters the shared file), notifies subscribers 
when the shared file has been updated or changed. 

One class of inter-program communication involves 65 
the request and provision of “services.” A service is a 
function or functionality provided by one program for 
use by another, where the functionality has a well de- 
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fined set of input types and a well defined set of output 
types. These services may include spell checkers, word 
definitions, synonyms, text editors, graphic editors, 
electronic mail, etc. In the prior art, services are pro- 
gram-dependent, that is, any available services must be 
provided by the program itself. In a few cases, services 
are provided by other programs, but only if the proto- 
col for a communication between the service requestor 
and the service provider is determined in advance. 
Therefore, in the prior art, external service programs 
are specific to and dependent on host programs. Data 
sharing oriented inter-program communication schemes 
such as hot links, warm links, and cold links are not used 
to share provide services for use by programs in the 
prior art. 

In a prior art multi-tasking environment, each appli- 
cation must have its own associated set of services. This 
results in duplication, for example, if all text editing 
applications require their own spell checkers. In addi- 
tion, it is generally not possible to add new services to 
existing applications. 

Data sharing communication schemes are not well 
suited to provide services to programs. It is therefore 
desired to provide an “algorithm-sharing” scheme so 
that programs requesting services can share the func- 
tionality of service providers. Formerly, algorithm 
sharing between programs could only take place if the 
service requestor “knew in advance” of the protocol for 
communication with a service provider. In other words, 
all inter-program communication is program-specific 
and the prior art does not provide a general solution for 
algorithm sharing. 

Therefore, it is an object of the present invention to 
provide a method and apparatus for providing a system 
for algorithm sharing among programs. 

It is another object of this invention to provide a 
system for services to be provided and used by pro- 
grams. 

It is another object of the present invention to pro- 
vide a system for providing algorithm sharing among 
programs that utilizes standard data transfer schemes. 

SUMMARY OF THE INVENTION 

A method and apparatus for providing inter-program 
communication is described. In particular, a “services 
server” scans programs stored in the mass storage of a 
computer system and generates a data structure contain- 
ing attribute information of each service provided by 
the programs stored in mass storage. This data structure 
includes an attribute name, the “send types” of the attri- 
bute and the “return types” of the attribute. A send type 
is the required format of data provided to the service 
provider as input to the service algorithm. The return 
type is the format of data that is the result of applying 
the algorithm to the input data. Send types and return 
types can be any arbitrary type but are most useful 
when they are types known by more than one applica- 
tion, e.g. ASCII, RTF, TIFF, PICT, tab-text, Post- 
Script, etc. 

When a service requestor is activated, the service 
requestor scans the services server data structure and 
generates its own local database of available services. In 
operation, a service requestor scans the database and 
retrieves only those services with which it can provide 
the appropriate format or protocol. For example, if a 
service requestor cannot communicate in graphical 
formats, such as PICT or TIFF, information about 
those service providers that require PICT or TIFF data 



5,446,896 


3 

on the server database are not retrieved. The service 
requestor then generates a display list, such as a menu of 
available services for a user. When a user wishes to 
access a service, the user makes a selection, which is 
data such as text, graphics, etc. Depending on the for- 5 
mat in which the selection can be represented, only 
certain of the initially available services may currently 
be valid. The displayed list of available services is con- 
tinuously updated to reflect the valid services. The user 
then chooses the desired service among the valid ser- ^ 
vices. The requesting program provides the selection to 
a service provider where an algorithm is executed and a 
return message may be generated for the service re- 
questor. 

15 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a computer system utiliz- 
ing the present invention. 

FIG. 2 is a block diagram of the preferred embodi- 
ment of this invention. 20 

FIG. 3 is a flow diagram illustrating the validReques- 
torForSendType.-AndRetumType: routine of this in- 
vention. 

FIG. 4A illustrates a services menu for a text editing 
application. 25 

FIG. 4B illustrates a services menu for a graphics 
application. 

FIG. 5 is a flow diagram illustrating the operation of 
this invention. 

30 

DETAILED DESCRIPTION OF THE 
INVENTION 

A method and apparatus for inter-program communi- 
cation is described. In the following description, numer- 35 
ous specific details, such as sending formats and receiv- 
ing formats, are described in detail in order to provide a 
more thorough description of this invention. It will be 
apparent, however, to one skilled in the art, that the 
present invention can be practiced without these spe- jq 
cific details. In other instances, well known features 
have not been described in detail so as not to obscure 
the present invention. 

The present invention may be implemented on any 
conventional or general purpose computer system. An 4.5 
example of one embodiment of a computer system for 
implementing this invention is illustrated in FIG. 1. A 
keyboard 10 and mouse 11 are coupled to a bi-direc- 
tional system bus 19. The keyboard and mouse are for 
introducing user input to the computer system and com- 50 
municating that user input to CPU 13. The computer 
system of FIG. 1 also includes a video memory 14, main 
memory 15 and mass storage 12, all coupled to bi-direc- 
tional system bus 19 along with keyboard 10, mouse 11 
and CPU 13. 55 

The mass storage 12 may include both fixed and re- 
movable media, such as magnetic, optical or magneto- 
optical storage systems or any other available mass 
storage technology. The mass storage may be shared on 
a network, or it may be dedicated mass storage. Bus 19 60 
may contain, for example, 32 address lines for address- 
ing video memory 14 or main memory 15. The system 
bus 19 also includes, for example, a 32-bit data bus for 
transferring data between and among the components, 
such as CPU 13, main memory 15, video memory 14 65 
and mass storage 12. Alternatively, multiplexed data- 
/address lines may be used instead of separate data and 
address lines. 
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In the preferred embodiment of this invention, the 
CPU 13 is a 32 bit microprocessor manufactured by 
Motorola, such as the 68030 or 68040. However, any 
other suitable microprocessor or microcomputer may 
be utilized. The Motorola microprocessor and its in- 
struction set, bus structure and control lines are de- 
scribed in MC68030 users manual and MC68040 users 
manual, published by Motorola, Inc. of Phoenix, Ariz. 

Main memory 15 is comprised of dynamic random 
access memory (DRAM) and in the preferred embodi- 
ment of this invention, comprises 8 megabytes of mem- 
ory. More or less memory may be used without depart- 
ing from the scope of this invention. The video memory 
14 is a dual ported video random access memory and in 
this invention consists, for example, of 256 kbytes of 
memory. However, more or less video memory may be 
provided as well. 

One port of the video memory 14 is coupled to video 
multiplexer and shifter 16 which in turn is coupled to 
video amplifier 17. The video amplifier 17 is used to 
drive the cathode ray tube (CRT) raster monitor 18. 
Video multiplexing shifter circuitry 16 and video ampli- 
fier 17 are well known in the art and may be imple- 
mented by any suitable means. This circuitry converts 
pixel data stored in video memory 14 to raster signal 
suitable for use by monitor 18. Monitor 18 is a type of 
monitor suitable for displaying graphic images, and in 
the preferred embodiment of this invention, has a reso- 
lution of approximately 1,020X832 high. Other resolu- 
tion monitors may be be utilized in this invention. In 
operation, the services server of this invention is an 
instruction set that is stored in main memory and exe- 
cuted by CPU 13. One Or more programs are stored in 
mass storage and paged into main memory, as needed, 
for access and execution by the CPU 13. 

The present invention provides a general solution for 
inter-program communication that allows services to be 
provided from a number of programs external to a re- 
questing program without prior knowledge of the re- 
questing program. 

A block diagram of the preferred embodiment of this 
invention is illustrated in FIG. 2. A services server 20 is 
implemented to coordinate and control communication 
between a number of service requestors 28 and service 
providers 23. The services server 20 communicates with 
one or more service providers 23 on line 22. The ser- 
vices server 20 also communicates with service request- 
ors on lines 24 and 25. The service requestors 28 com- 
municate with service providers 23 on lines 26 and 27. 
Although individual lines are shown for communication 
between the services server, service requestor and ser- 
vice providers, the communication can take place on 
bi-directional bus 19 of FIG. 1. 

In a computer system, there may be a number of 
service providers, such as service providers 23A, 23B 
through 23N. These service providers can provide ser- 
vices, such as electronic mail, on-line dictionary, the- 
saurus, spell checking, graphic editing, etc. In addition, 
there may be one or more service requestors, such as 
service requestors 28A, 28B through 28N. It should be 
noted that a service provider may also be a service 
requestor in certain circumstances and vice versa. 

SERVICES SERVER 

The services server 20 polls all service providers 
available to a computer system to generate a services 
database 21. The services database 21 contains the attri- 
butes of each service provided by the service providers. 
The attributes include the service name, the location or 
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port of the service, the service message and the service 
sendTypes and retumTypes. It may also include other 
information pertinent to providing the service such as a 
timeout or provider known, requestor-opaque data. 

The service name is the name of the service as it 5 
appears in a menu of a service requestor. For example, 
an electronic mail service provider may be identified by 
the menu name “MAIL” in the services menu of a ser- 
vice requestor. The location or port information is used 
to properly route service requests to the appropriate 10 
service provider. The port may have the same name as 
the name of the service. The service message is a mes- 
sage that must accompany a service request to obtain 
that particular service, since multiple services can be 
provided on a single port. 15 

SendTypes is a list of formats that can be accepted by 
a service provider. For example, if the service provider 
operates on text, it may accept sendTypes of ASCII, 
RTF (rich text format), etc. Correspondingly, the re- 
tumType identifies the formats of information provided 20 
by a service provider to a service requestor. The retum- 
Types need not have a one-to-one correspondence with 
the sendTypes. For example, a service provider may be 
able to accept data in ASCII or RTF, but only provide 
return data in ASCII format. Other send and return 25 
types include TIFF, PICT, etc. In addition, either the 
sendType or retumType may be null. 

The service server generates a service database 21. 
This database is stored in main memory 15 and appears 
as follows in Table 1: 30 
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is sent to specify the particular service desired at a port 
that permits access to more than one service. For exam- 
ple, the message “send document” is provided to the 
MAIL port to access the MAIL DOCUMENT service. 
The message “send selection” is sent to the MAIL port 
to access the MAIL SELECTION service. 

SERVICE REOUESTOR 

When a service requestor is initialized or, alterna- 
tively, at the time of each service request, the service 
requestor polls the database 21 of the services server 
and generates a local data structure, such as local data 
structures 29A, 29B and 29N. This local data structure 
is a list of services that the service requestor can request, 
i.e. the service requestor can provide and receive the 
data types. A service requestor may not be able to com- 
municate with some service providers because the ser- 
vice requestor may not be able to provide data of the 
specified sendTypes or receive data back of the speci- 
fied retumTypes that those service providers’ algo- 
rithms require. Therefore, by building a local data 
structure specific to each service requestor, only those 
services that can actually be accessed by the service 
requestor will be displayed in the service requestors’ 
menu. 


THE 

REGISTERSERVICESMENUSENDTYPES:AN- 
DRETURNTYPES: ROUTINE 

Service requestors register their intent to avail them- 
selves of services with given sendTypes and retum- 


TABLE 1 


Name 

Port 

Message 

SendType 

RetumType 

CAPITALIZE WORD 

CAPITALIZE 

CAPITALIZE 

RTF 

ASCII, RTF 

DEFINE WORD 

DICTIONARY 

DEFINE 

ASCII, RTF 

Null 

SPELL 

DICTIONARY 

SPELL 

ASCII RTF 

ASCII, RTF 

SORT 

SORT 

SORT 

ASCII, RTF 

ASCII, RTF 

MAIL DOCUMENT 

MAIL 

SEND DOCUMENT 

File 

Null 

MAIL SELECTION 

MAIL 

SEND SELECTION 

ALL TYPES 

NULL 

CHART 

CHART 


TAB-TEXT 

PostScript, TIFF, PICT 

TIMESTAMP 

TIME 

STAMP 

NULL 

ASCII 

ROTATE 

GRAPHICS 

ROTATE 

PostScript, TIFF, PICT 

PostScript, TIFF, PICT 


In the example of Table 1, a services name, port, 
message, sendType and retumType are shown. In this 
example, there are nine services available, namely, 
CAPITALIZE WORD, DEFINE WORD, SPELL, 45 
SORT, MAIL DOCUMENT, MAIL SELECTION, 
CHART, TIMESTAMP, and ROTATE. 

In the example shown, the port ID of some services is 
shown to be the same as the name of the service. This is 
for purposes of example only and the invention is not 50 
limited to this embodiment. In addition, the sendTypes 
and retumTypes of FIG. 3 are not intended to be ex- 
haustive but merely representative. 

Services that have non-null retumTypes are referred 
to as “synchronous” services. Synchronous services 55 
may transfer data and always expect data in response. 
Examples of synchronous services include CAPITAL- 
IZE WORD, SPELL, SORT, CHART, TIMES- 
TAMP and ROTATE. 

A service that has a null retumType is referred to 60 
herein as an “asynchronous” service. Examples of an 
asynchronous service are DEFINE WORD, MAIL 
DOCUMENT, and MAIL SELECTION. 

More than one service may be accessed at a single 
port. For example, both MAIL DOCUMENT and 65 
MAIL SELECTION are accessed at the MAIL port. 
Likewise, both DEFINE WORD and SPELL are ac- 
cessed at the DICTIONARY port. A different message 


Types via a routine, referred to as “registerServices- 
MenuSendTypes:AndRetumTypes:”. For example, a 
service provider registers that it can send and receive in 
ASCII or RTF. All services that send and receive in 
ASCII or RTF are then made part of the service re- 
questor’s local data structure. For each registered send- 
Types/retumTypes combination, those services in the 
global services database that have matching send and 
receive types are registered in the local data structure. 

The format is as follows: 

registerServicesMenuSendTypes: (const char *const 
*)sendTypes andRetumTypes: (const char ‘const 
*)retumTypes. 

This routine is executed with each of the various 
sendTypes that a service requestor is able to send to a 
service provider paired with the corresponding retum- 
Types a service requestor can receive in return from a 
service provider. Any combination of sendTypes and 
retumTypes can be registered including NULL for 
either. Cases of multiple sendTypes or retumTypes are 
automatically degenerated to all possible combinations. 
For example, if a requestor can send ASCII or RTF and 
get ASCII or RTF in return, it can also participate in 
any service that takes ASCII only and gives nothing in 
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return, or one that takes RTF only and returns ASCII 
only. Using this routine, a local data structure is gener- 
ated. 

The operation of this routine is illustrated with refer- 
ence to Table 1. Consider the case where a word pro- 5 
cessing program is initialized. The registerServices- 
MenuSendTypes:AndRetumTypes: routine is executed 
with arguments sendTypes = ASCII, RTF and retum- 
Types=ASCII, RTF. Therefore, the services CAPI- 
TALIZE WORD, SPELL, and SORT are included in io 
the local database. The services DEFINE WORD and 
MAIL SELECTION are also included, even though 
they do not return ASCII information. These services 
are asynchronous and it is assumed that service request- 
ors can send an asynchronous message with the speci- 15 
fled sendTypes of data and receive nothing back, be- 
cause of the degeneration described above. TIMES- 
TAMPS is also included by degenerating its sendTypes 
to be null and its returaTypes to be ASCII. 

THE 20 

VALIDREQUESTORFORSENDTYPE:AN- 
DRETURNTYPE: ROUTINE 


user’s attention is made. These objects are referred to in 
the preferred embodiment as a “responder chain” con- 
sisting of the first responder (the last area the user 
worked with the mouse), key window, (the window 
currently “active”), the key window’s delegate, (an 
object delegated by the key window), the program 
object, (representing the whole program), and its dele- 
gate, if any, is performed at step 34. If there is an object 
in the responder chain that can participate in requesting, 
it returns itself to this message if it is able to provide 
data of the requested type. Based on the review of the 
responder chain at step 34, the system generates new 
menu selections or updates old menu selections at step 
35. Such a review is specific only to the preferred em- 
bodiment. However, any method of tracking the selec- 
tion made may be utilized without departing from the 
scope of this invention. 

For example, if a user is using a program and is edit- 
ing text, the services menu might appear as in FIG. 4A. 
In FIG. 4A, only the services CAPITALIZE WORD, 
DEFINE WORD, SPELL, SORT, MAIL SELEC- 
TION, MAIL DOCUMENT, and TIMESTAMP are 


The local data structure of a service requestor stores 
all the services that may be accessed by a service re- 25 
questor. However, only those services that are valid for 
a particular selection in a service requestor are available 
in a service menu at any one time. The validRequestor- 
ForSendT ype: AndReturnT ype: routine is utilized to 
determine which object in the service requestor is cur- 30 
rently prepared to make a request with a given send- 
Type and retumType. By finding those sendType/- 
retumType pairs that have valid requesting objects, it is 
possible to determine at any given time which services 
are currently valid overall. It is set forth below: 


available. CAPITALIZE WORD, DEFINE WORD, 
SPELL, SORT, and MAIL SELECTION are avail- 
able because the selection is usually ASCII or RTF 
sendType. The MAIL DOCUMENT service is avail- 
able because the program is always able to provide the 
entire document as type file. The TIMESTAMP ser- 
vice is available because it does not require any send- 
Type to be valid. The CHART and ROTATE services 
are disabled (shown as gray text) in FIG. 4A because 
the current selection is not a valid sendType of an argu- 
ment to those services (i.e., the selection does not con- 
tain graphical data). 


validRequestorForSendType: (NXAtom)sendType 
AndReturnType: (NXAtom)retumType. 


In a program when the user is currently editing 
graphics, the services menu might appear as in FIG. 4B, 
with MAIL SELECTION, MAIL DOCUMENT and 


The validRequestorForSendType:AndRetumType: 
routine is executed on the occurrence of each event of 40 
a program. An event is defined here as a mouse click, a 
drag, typing of characters, selection of text or graphics, 
etc. For example, if a string of text is selected, the ser- 
vice ROTATE is not available, because there is no 
object in the service requestor that can provide Post- 45 
Script, TIFF or PICT as an argument to a service. 
Therefore, the ROTATE service does not appear as a 
valid service in the services menu of the service re- 
questor, or the the menu selection for ROTATE is 
disabled. Similarly, if a graphic is selected in a docu- 50 
ment, the CAPITALIZE WORD, DEFINE WORD, 
SPELL, SORT, MAIL DOCUMENT, and CHART 
services are not available and only the ROTATE and 
MAIL SELECTION services are enabled. In this man- 
ner, only those services that can be executed for the 55 
particular selection are valid at any one time. 

A flow chart of the operation of validRequestorFor- 
SendType:AndRetumType: is illustrated in FIG. 3. 
The process starts at block 30 and the program is run- 
ning. At block 31, the process waits for an event to 60 
occur. When an event occurs, the system proceeds to 
step 32 and program specific processing takes place. 

At step 32, after an event, program specific process- 
ing occurs that may or may not affect whether a valid 
requesting selection exists in the service requestor (e.g. 65 
the user may select data that can be represented in a 
format appropriate for a service). A review of the ob- 
jects that are selected by the user or are the focus of the 


ROTATE as valid services and CAPITALIZE 
WORD, DEFINE WORD, SPELL, SORT, TIMES- 
TAMP and CHART disabled. If the user begins editing 
text, those services would be enabled. 

THE 

WRITESELECTIONTOPASTEBOARD:TYPES: 

ROUTINE 

The present invention provides an algorithm sharing 
scheme for services to be provided and used by pro- 
grams. This scheme takes advantage of existing data 
transfer techniques known as “clipboard” or “paste- 
board”. For purposes of example, this invention is de- 
scribed herein as implemented in a pasteboard environ- 
ment. A pasteboard is a temporary storage location of 
data that is to be transferred from one program to an- 
other, or to store data that is to be moved from one part 
of a file to another. The technique of using a pasteboard 
for temporary storage of data to be transferred is also 
known as “cut and paste” or “copy and paste” and is 
well documented in the prior art. 

To use a service, typically an “object” is responsible 
for a selection by a user. An object may be a key win- 
dow or first responder or application object. The object 
returned by a call to validRequestorForSendType:An- 
dRetumType: must respond to the following routine: 

(BOOL) writeSelectionToPasteboard: (ID) 
pasteboard types: (NXAtom *) types 
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Transfer of data between service requestors and 
service providers in the preferred embodiment of this 
invention is accomplished through a pasteboard. As 
implemented on the NeXT Computer System, (manu- 
factured by NEXT, Inc. of Redwood City, Calif.), a 5 
plurality of pasteboards can be defined for use by a 
number of programs. In the preferred embodiment, 
each service request transaction generates its own paste- 
board. At the time a service request is made, the re- 
sponder chain is again queried via thevalidRequestor- 10 
ForSendType:AndRetumType: message to determine 
which object should be sent to writeSelectionToPas- 
teboard:types:. 

If a service provider can accept sendTypes of more 
than one type (i.e., types, the argument to writeSelec- 15 
tionToPasteboard:type has more than one type in it), 
only one type need be provided. However, the service 
requestor may provide as many as all sendTypes (if it is 
able to do so) to the service provider, because the ser- 
vice provider may be able to operate more effectively 20 
on one sendType than another. The service requestor 
only is required, however, to provide one sendType. 
The service provider is launched, if necessary, so that it 
may provide the appropriate service. 

If the service provider provides asynchronous ser- 25 
vice, no response is provided to the service requestor 
through the pasteboard. However, a message or other 
form of information may appear on the user screen such 
as a definition of a word. If the service provider is a 
synchronous service provider, such as CAPITALIZE, 30 
data is returned to the service requestor after manipula- 
tion by the service provider via the same pasteboard 
used to send the original data to the service provider. 

THE READSELECTIONFROMPASTEBOARD: 35 
ROUTINE: 

For synchronous services, the following routine is 
implemented in the service requestor after receiving a 
response to a service request. 

40 

readSelectionFromPastcboard: (id) pboard 

This operation is implemented by the service re- 
questor and simply involves replacing the selection 
placed in the pasteboard by the service requestor with 45 
the data currently in the pasteboard, provided by the 
service provider. The service provider must provide 
back to a service requestor all retumTypes published by 
the service provider. For example, if a service requestor 
provided ASCII text to a service provider, and the 50 
service provider has retumTypes of ASCII and RTF, 
both ASCII and RTF must be provided back to the 
service requestor, regardless of what sendTypes were 
actually sent by the service requestor. In the preferred 
embodiment, usually only one or none of the represen- 55 
tations of the data is actually placed in the pasteboard 
while the other types are “offered” to the service re- 
questor (or service provider in the case of writeSelec- 
tionToPasteboard:types:). If the service requestor de- 
sires the type that was not initially provided, the paste- 60 
board mechanism accesses the service provider and 
requests the offered data that is then generated by the 
service provider and placed in the pasteboard. 

The general operation of this invention is described 
with respect to FIG. 5. At block 50, the services server 65 
scans the mass storage of the computer system for all 
service providers. At step 51, the services server builds 
the primary services database. As noted previously, this 
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database consists of the services, their ports, messages, 
sendTypes and retumTypes. 

At step 52, usually coincident with the initialization 
of service requestor programs, the registerServices- 
MenuSendTypes:AndRetumTypes: subroutine is exe- 
cuted. This subroutine is shown at steps 53-55. At step 
53, the registerServicesMenuSendTypes:AndRetum- 
Types: begins. At step 54, the sendTypes and retum- 
Types of the service requestor are registered. At step 
55, the local database is generated, based on the send- 
Types and retumTypes registered by the service re- 
questor. 

At step 58, the user makes a selection. The menu of 
services is updated at step 59 based on the data types in 
which the selection the user has made can be repre- 
sented and on the SendTypes of the services in the local 
database. At step 60, the user selects a service provider 
from the menu. 

At step 61, a valid requestor is again invoked to find 
the object in the service requestor which will supply the 
data for the chosen service. 

At step 62, the object is written to the pasteboard so 
that it can be accessed by the service provider. At step 
63, an inter-application message is sent to the service 
provider. At step 64, the service provider actually pro- 
vides its service. At step 65, the service requestor reads 
the return object from the pasteboard if the service is a 
synchronous service. The system then returns to step 
58. 

One of the features of this invention is that it enables 
programs to cooperate in algorithm sharing without 
prior knowledge of each other, that is, one program 
does not need to be written with another program in 
mind to allow algorithm sharing. Services communica- 
tion (namely, matching service requestors and provid- 
ers via their sendTypes and retumTypes, and communi- 
cation by a send message and a return message) is one 
example of algorithm sharing. The present invention is 
not limited to the provision of these types of services. 
For example, the present invention permits algorithm 
sharing between any programs that can operate on mu- 
tually acceptable data types. In the preferred embodi- 
ment, the invention takes advantage of existing data 
transferring mechanisms, such as pasteboard. 

The invention provides a method of sharing algo- 
rithms between algorithm providers and algorithm re- 
questors by 1) creating a database of all algorithm pro- 
viders; 2) creating local databases for each algorithm 
requestor of algorithm providers capable of sharing 
algorithms with that algorithm requestor by identifying 
data types that can be provided by an algorithm re- 
questor and operated on by an algorithm provider; 3) 
generating valid requestors based on data types cur- 
rently selected by the user in an algorithm requestor; 4) 
providing a mechanism for initiating the algorithm shar- 
ing process; and 5) transferring data between the algo- 
rithm requestor and the algorithm provider. 

The global database is created and maintained by any 
acceptable means, such as a server or other supervisory 
functionality. One example of a means for creating such 
a database is the services server described herein. The 
local database may be created by a registration scheme 
as described above. The requirements of a registration 
scheme are that the algorithm requestor registers all 
data types that it can send and receive. All algorithm 
providers that can send and or receive at least one of the 
same data types is made part of the local database of that 
algorithm requestor. 
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Valid requests are determined periodically, (such as 
at the occurrence of an event). In this way, only those 
algorithm providers that are capable of operating on 
data types that are currently selected by a user or are 
the object of interest of a user are enabled. One example 5 
of a method for validating requests is described above in 
connection with the validRequestorFor SendTypes- 
:AndRetumTypes: routine. 

The algorithm sharing process is initiated by a user, 
generally by selecting an algorithm provider from a 10 
menu of enabled and valid algorithm providers. At that 
point, data is transferred between the algorithm re- 
questor and algorithm provider, using any acceptable 
data transfer mechanism, such as clipboard or paste- 
board. 15 

The algorithm sharing scheme of this invention can 
operate on data in many forms, such as in discrete 
blocks as described above. Another style of data com- 
munication suitable for this invention enables a service 
provider to operate on a service requestor’s data as a 20 
stream. While processing this stream, the service pro- 
vider may require interaction with the user, and may 
wish to give feedback in the service requestor’s view of 
the data. 

For example, consider a spell checking service. One 25 
user interface is to present the user with a panel with 
choices, such as “Find next misspelled word,” “Guess 
correct spelling,” or “Learn selected word in dictio- 
nary.” A user begins by choosing “Find.” A misspelled 
word is selected in the text the user is spell checking. If 30 
it is a misspelled word, the user may choose “Guess” to 
find the correct spelling, or simply type in the correc- 
tion. If it is a correct spelling, he may choose “Learn” 
so the spell checker can add this word to its dictionary. 
The user can then use “Find” to go on to the next word 35 
of interest. 

This service requires that the service provider be able 
to request data as needed from the requestor as its task 
or service is performed. The service provider must be 
able to select words in the requestor so as to give feed- 40 
back to the user for words that require further action. 
Also, the service provider must be able to apply 
changes to pieces of the requestor’s data as it operates 
on the data. 

The interactive algorithm sharing described above is 45 
referred to herein as “stream services.” In this algo- 
rithm sharing implementation, a service requestor regis- 
ters to participate in stream services upon startup by 
executing a registerStreamService subroutine. The 
registerStreamService subroutine identifies the service 50 
requestor as a program that is capable of participating in 
generalized algorithm sharing. 

The service requestor implements a set of methods to 
participate in stream services. A “beginStream” subrou- 
tine is sent to the service requestor at the start of a 55 
stream service interaction, allowing the service re- 
questor to do any necessary initialization. 

A “getData” routine is implemented to return addi- 
tional data to the service provider from the source text 
in the service requestor starting at the current position 60 
in the data stream. The current position in the data 
stream is established by a “Seek” routine. A “Tell” 
routine is implemented to return the current position in 
the stream. 

A “Select” routine is implemented to select some data 65 
within the data stream. Operation of the Select routine 
may or may not affect the current position. “Insert” is 
implemented to insert data over the current selection. 
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“Deletion” is performed by making a selection with 
Select, and then using inserting zero bytes. The “end- 
Stream” routine is sent to the service requestor at the 
end of a stream service interaction, allowing the service 
requestor to do any necessary cleanup. 

A service provider must implement a “provide- 
StreamService” routine with the service provider at the 
start of a stream service interaction. The service pro- 
vider receives an object to which it can send the various 
methods described above that are implemented by the 
service requestor. 

Another service that implements algorithm sharing of 
a stream of data is a language translation service. This 
service can read source text from the requestor in a 
stream fashion. It may need to interact with the user to 
disambiguate various options in translation. 

Thus, a method and apparatus for inter-program 
communication and algorithm sharing has been de- 
scribed. 

We claim: 

1. A method for providing communication between a 
service requestor program and a plurality of service 
provider programs resident on a computer system, said 
service provider programs each executing a service on 
data provided by said service requestor program, said 
method comprising the steps of: 

scanning by a supervisory process said plurality of 
service provider programs to generate a primary 
database of said service provider programs, said 
primary database including a name of each of said 
plurality of said service provider programs, any 
sendTypes associated with each of said service 
provider programs, where a sendType is a data 
type that can be read by a service provider pro- 
gram, and any retumTypes associated with each of 
said service provider programs, where a retum- 
Type is a data type that is provided by a service 
provider program; 

comparing said sendTypes and said retumTypes of 
each service provider program with sendTypes 
and retumTypes registered by said service re- 
questor program; 

generating a local database for said service requestor 
program, said local database comprising each ser- 
vice provider program having at least one send- 
Type and retumType matching a sendType and 
retumType of said service requestor program; 

selecting data provided by said service requestor 
program, said data having an associated object 
sendType; 

enabling each of said service provider programs of 
said local database capable of accepting a send- 
Type of said object sendType; 

providing said data to one of said enabled service 
provider programs; 

executing a service on said data by said one service 
provider program. 

2. The method of claim 1 wherein said supervisory 
process is a services server. 

3. The method of claim 1 wherein said step of com- 
paring said sendTypes and retumTypes of said service 
requestor program with said service provider program, 
and said step of generating said local database, is per- 
formed when said service requestor program is initial- 
ized. 

4. The method of claim 1 wherein said step of en- 
abling said service provider programs is performed at 
periodic times. 
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5. The method of claim 1 wherein said step of en- 
abling said service provider programs is performed 
when an event occurs. 

6. The method of claim 1 wherein a service provider 
program having at least one sendType and no return- 5 
Types is defined as an asynchronous service provider 
program. 

7. The method of claim 1 wherein a service provider 

program having at least one retumType is defined as a 
synchronous service provider program. ^ 

8. The method of claim 1 wherein said step of provid- 
ing said data to said service provider program is per- 
formed by providing said data to a temporary storage 
location shared by said service provider programs. 

9. The method of claim 8 wherein said temporary 
storage location comprises a pasteboard memory. 

10. The method of claim 1 wherein said sendTypes 

and said retumTypes include ASCII, RTF, Postscript, 
TIFF and PICT data types. 20 

11. A method for providing co mmuni cation between 
a service requestor program and a plurality of service 
provider programs resident on a computer system, said 
service provider programs each executing a service on 
data provided by said service requestor program, said 25 
method comprising the steps of: 

scanning by a supervisory process said plurality of 
service provider programs to generate a primary 
database of said service provider programs, said 
primary database including a name of each of said 30 
plurality of said service provider programs, any 
sendTypes associated with each of said service 
provider programs, where a sendType is a data 
type that can be read by a service provider pro- 
gram, and any retumTypes associated with each of 35 
said service provider programs, where a retum- 
Type is a data type that is provided by a service 
provider program; 

comparing said sendTypes and said retumTypes of 
each service provider program with sendTypes 40 
and retumTypes registered by said service re- 
questor program; 

generating a local database for said service requestor 
program, said local database comprising each ser- 
vice provider program having at least one send- 45 
Type and retumType matching a sendType and 
retumType of said service requestor program; 

selecting data provided by said service requestor 
program, said data having an associated object 
sendType; u 

generating a menu on a display of each of said service 
provider programs of said local database capable of 
accepting a sendType of said object sendType; 

selecting one of said service provider programs from 55 
said menu; 

providing said data to said one service provider pro- 
gram; 

executing a service on said data by said one service 
provider program. gg 

12. The method of claim 11 wherein said supervisory 
process comprises a services server. 

13. The method of claim 11 wherein said step of com- 
paring said sendTypes and retumTypes of said service 
requestor program with said service provider program, 65 
and said step of generating said local database, is per- 
formed when said service requestor program is initial- 
ized. 
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14. The method of claim 11 wherein said step of en- 
abling said service provider programs is performed at 
periodic times. 

15. The method of claim 11 wherein said step of en- 
abling said service provider programs is performed 
when an event occurs. 

16. The method of claim 11 wherein a service pro- 
vider program having at least one sendType and no 
retumTypes is defined as an asynchronous service pro- 
vider program. 

17. The method of claim 11 wherein a service pro- 
vider program having at least one retumType is defined 
as a synchronous service provider program. 

18. The method of claim 11 wherein said step of pro- 
viding said data to said service provider program is 
performed by providing said data to a temporary stor- 
age location shared by said service provider programs. 

19. The method of claim 18 wherein said temporary 
storage location comprises a pasteboard memory. 

20. The method of claim 11 wherein said sendTypes 
and said retumTypes include ASCII, RTF, Postscript, 
TIFF and PICT data types. 

21. An apparatus for inter-program communication 
comprising: 

mass storage means for storing a plurality of service 
provider programs; 

supervisory process coupled to said mass storage 
means for scanning said plurality of service pro- 
vider programs to generate a primary database; 

first storage means coupled to said processing means 
for storing said primary database, said primary 
database including a name of each of said plurality 
of service provider programs, any sendTypes asso- 
ciated with each of said plurality of service pro- 
vider programs, where a sendType is a data type 
that can be read by a service provider program, 
and any retumTypes associated with each of said 
plurality of service provider programs, where a 
retumType is a data type that is provided by a 
service provider program; 

service requestor coupled to said first storage means, 
said service requestor comparing said sendTypes 
and said retumTypes of each service provider pro- 
gram with sendTypes and retumTypes associated 
with said service requestor; 

second storage means coupled to said service re- 
questor for storing a local database, said local data- 
base comprising each service provider program 
having at least one sendType and retumType 
matching a sendType and retumType of said ser- 
vice requestor program; 

third storage means coupled to said service requestor 
and said services server for storing data of said 
service requestor; 

service provider coupled to said third storage means 
for executing one of said plurality of service pro- 
vider programs to operate on said data. 

22. The apparatus of claim 21 wherein first storage 
means comprises a services server. 

23. The apparatus of claim 21 wherein said service 
requestor generates a display menu of each of said ser- 
vice provider programs from said data stored in said 
local database. 

24. The apparatus of claim 22 wherein said supervi- 
sory process, said service requestor, and said service 
provider are implemented with a microprocessor. 
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25. The apparatus of claim 21 wherein a service pro- 
vider program having at least one retumType is defined 
as a synchronous service provider program. 

26. The apparatus of claim 21 wherein said third 

storage means comprises a pasteboard memory. 5 

27. The apparatus of claim 21 wherein said sendTypes 
and said retumTypes include ASCII, RTF, Postscript, 
TIFF and PICT data types. 

28. The apparatus of cl aim 21 further including en- 
abling means coupled to said menu generating means ^ 
for enabling said display menu only for those of said 
service provider programs that can currently provide a 
service to said service requestor program. 

29. A method for providing algorithm sharing be- 

tween a service requestor program and a plurality of 
service provider programs resident on a computer sys- 
tem, said service provider programs each executing a 
service on data provided by said service requestor pro- 
gram, said method comprising the steps of: 20 

scanning by a services server said plurality of service 
provider programs to define a primary database of 
service providers comprising attributes of said plu- 
rality of service provider programs; 

scanning said primary database to generate a local 25 
database of valid services for said service requestor 
program by comparing said attributes of said plu- 
rality of service provider programs in the primary 
database to capabilities registered by said service 
requestor program; 30 

selecting data in said service requestor program; 

enabling each of said service provider programs in 
said local database capable of acting on said se- 
lected data; 

performing one of said services on said data by trans- 35 
ferring said data between said service requestor 
program and a service provider performing said 
one service. 

30. The method of claim 29 wherein said attributes of 

a service provider program comprise a service provider 40 
name, a list of sendTypes, where a sendType is a data 
type that can be read by said service provider program, 
and a list of retumTypes, where a retumType is a data 
type that can be provided by said service provider pro- 
gram. 5 

31. The method of claim 30 wherein data is trans- 
ferred by one or both of: 

a. sending data within the service requestor program 

to said service provider program; 50 

b. returning data from said service provider program 
to said service requestor program. 

32. An apparatus for supervising message passing in a 
computer system comprising; 

supervisory function having a first and second com- 55 
munication line for sending and receiving mes- 
sages; 

requestor function coupled to said supervisory func- 
tion via said first communication line, said re- 
questor function sending messages to and receiving 60 
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messages from said supervisory function via said 
first communication line; 
provider function coupled to said supervisory func- 
tion via said second communication line, said pro- 
vider function sending messages to and receiving 
messages from said supervisory function via said 
second communication line; 
said supervisory function supervising messages be- 
tween said requestor and provider functions. 

33. A method for sharing algorithms between a plu- 
rality of algorithm requestors and a plurality of algo- 
rithm providers comprising the steps of: 

scanning by a supervisory function a plurality of 
algorithm providers to generate a primary database 
containing attribute information of each of said 
plurality of algorithm providers; 
examining by a first one of said plurality of algorithm 
requestors each entry in said primary database to 
generate a local database, said local database con- 
taining information associated with each of said 
plurality of algorithm providers whose attribute 
information is compatible with the requirements of 
said first algorithm requestor; 
enabling each of said compatible algorithm providers; 
selecting one of said compatible algorithm providers, 
said first one of said compatible algorithm provid- 
ers accessible by at least a second one of said plural- 
ity of algorithm requestors; 
transferring data between said algorithm requestor 
and said one of said compatible algorithm provid- 
ers. 

34. The method of claim 33 further comprising the 
steps of: 

examining by said second one of said plurality of 
algorithm requestors each entry in said primary 
database to generate a second local database, said 
second local database containing information asso- 
ciated with each of said plurality of algorithm pro- 
viders whose attribute information is compatible 
with the requirements of said second algorithm 
requestor, said second local database including said 
first one of said compatible algorithm providers; 
enabling each of said plurality of algorithm providers 
compatible with said second algorithm requestor 
including said first one of said compatible algo- 
rithm providers; 

selecting said first one of said compatible algorithm 
providers; 

transferring data between said first algorithm re- 
questor and said one of said compatible algorithm 
providers. 

35. The method of claim 33 further comprising the 
steps of: 

transferring to said first one of said plurality of algo- 
rithm requestors a request by said one of said first 
compatible algorithm providers for additional data, 
transferring from said first one of said plurality of 
algorithm requestors to said one of said first com- 
patible algorithm providers said additional data. 
***** 
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